When a user interacts with sites on the Internet (hereafter referred to as “service providers” or “relying parties”), the service provider often expects to know something about the user that is requesting the services of the provider. The typical approach for a service provider is to require the user to log into or authenticate to the service provider's computer system. But this approach, while satisfactory for the service provider, is less than ideal to the user. First, the user must remember a username and password for each service provider who expects such information. Given that different computer systems impose different requirements, and the possibility that another user might have chosen the same username, the user might be unable to use the same username/password combination on each such computer system. (There is also the related problem that if the user uses the same username/password combination on multiple computer systems, someone who hacks one such computer system would be able to access other such computer systems.) Second, the user has no control over how the service provider uses the information it stores. If the service provider uses the stored information in a way the user does not want, the user has relatively little ability to prevent such abuse, or recourse after the fact.
To address this problem, new systems have been developed that allow the user a measure of control over the information stored about the user. Windows CardSpace™ (sometimes called CardSpace) is a Microsoft implementation of an identity meta-system that offers a solution to this problem. (Microsoft, Windows, and CardSpace are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.) A user can store identity information with an identity provider the user trusts. When a service provider wants some information about the user, the user can control the release of information stored with the identity provider to the service provider. The user can then use the offered services that required the identity information.
One problem with this model is that the service provider is only concerned with making sure the service provider is not defrauded by someone posing as the user. The service provider is concerned with protecting their legal liability, not in protecting the user's information. While this concern partially parallels a concern of the user, the concerns do not overlap.
Another problem can occur if a third party is able to convince the identity provider to release the user's information (for example, by sufficiently “authenticating” to the identity provider as the user): the user has no way to know this release has occurred. Such a subversion of information, commonly termed “identity theft” today, is a major concern to users whose identities are stolen. Users whose identities are stolen face a major hassle in clearing the record of the charges made improperly in their names: this hassle can sometimes takes years to resolve and can have major financial implications for the users in the long term. For example, charges that are not paid are often reported to credit bureaus and have a negative impact on the users' credit ratings. A user who was about to take out a mortgage to purchase a house might find themselves forced to pay a higher interest rate or be considered a higher risk loan borrower. This kind of impact to users can be even more onerous than the time it takes to fix the records at the credit bureaus.
Banks also suffer as a consequence of identity theft. If a bank makes a payment ostensibly on behalf of a user but that was actually charged by someone who had stolen the user's identity, the bank will probably not be able to recover the lost funds. For example, credit card agreements often agree to limit customer liability for fraudulent charges to $50 if the customer reports the fraudulent charge quickly enough. As both the user and the merchant were relying on the bank to properly authenticate the user before issuing payment, the bank usually ends up bearing the loss for the fraud.
Yet another problem with this model is that the use of such systems requires that the information card(s) be stored on the local machine. If the user is using a machine that is not generally available to the public (for example, a work computer or a computer in the user's home), this limitation might not be a great concern. But if a user is attempting to perform the transaction from a public computer, such as a computer in a public library, the user might not want to install such information cards on the public computer. First, it might not be possible to remove the information cards once installed. Second, the user might forget to uninstall the information cards, leaving them on the computer where someone else might be able to access and use them.
A need remains for a way to addresses these and other problems associated with the prior art.